图文详解k8s自动化持续集成之GitLab CI/CD

持续集成的好处主要有两个:

　　每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易

　　如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

首先需要有一台 GitLab 服务器，然后需要有个项目；这里示例项目以 golang 项目为例，然后最好有一台专门用来 Build 的机器，实际生产中如果 Build 任务不频繁可适当用一些业务机器进行 Build；本文示例所有组件将采用 Docker 启动， GitLab HA 等不在本文阐述范围内

GitLab CI 是 GitLab 默认集成的 CI 功能，GitLab CI 通过在项目内 .gitlab-ci.yaml 配置文件读取 CI 任务并进行相应处理；GitLab CI 通过其称为 GitLab Runner 的 Agent 端进行 build 操作；Runner 本身可以使用多种方式安装，比如使用 Docker 镜像启动等；Runner 在进行 build 操作时也可以选择多种 build 环境提供者；比如直接在 Runner 所在宿主机 build、通过新创建虚拟机(vmware、virtualbox)进行 build等；同时 Runner 支持 Docker 作为 build 提供者，即每次 build 新启动容器进行 build；GitLab CI 其大致架构如下

Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。

已经有gitlab的同学，可以跳过。GitLab 搭建这里直接使用 docker compose 启动，compose 配置如下

直接启动后，首次登陆需要设置初始密码如下，默认用户为 root登陆成功后创建一个用户(该用户最好给予 Admin 权限，以后操作以该用户为例)，并且创建一个测试 Group 和 Project.

这里示例项目采用 Golang 的 Fingerprint 项目，并采用 go module 构建，其他语言原理一样；如果不熟悉 golang 的没必要死磕此步配置，任意语言整一个能用的项目就行，并不强求特定语言、框架构建，以下只是一个样例项目，如下所示：

最后将项目提交到 GitLab 后如下

针对这一章节创建基础镜像以及项目镜像，这里仅以 Go 项目为例；其他语言原理相通，按照其他语言对应的运行环境修改即可

GitLab CI 在进行构建时会将任务下发给 Runner，让 Runner 去执行；所以先要添加一个 Runner，Runner 这里采用 Docker in docker 启动，build 方式也使用 Docker 方式 Build；命令如下：

在执行上一条激活命令后，会按照提示让你输入一些信息；首先输入 GitLab 地址，然后是 Runner Token，Runner Token 可以从 GitLab 设置中查看，如下所示

注册完成后，在 GitLab Runner 设置中就可以看到刚刚注册的 Runner，如下所示

注意，这里声明的 Volumes 会在每个运行的容器中都生效；也就是说 build 时新开启的每个容器都会被挂载这些目录；修改完成后重启 runner 容器即可。

针对于项目每次 build 都应该生成一个包含发布物的 docker 镜像，所以对于项目来说还需要一个项目本身的 Dockerfile；项目的 Dockerfile 有两种使用方式；一种是动态生成 Dockerfile，然后每次使用新生成的 Dockerfile 去 build；还有一种是写一个通用的 Dockerfile，build 时利用 ARG、onbuild、CMD 参数传入变量；这里采用第二种方式，以下为一个可以反复使用的 Dockerfile：

一切准备就绪以后，就可以编写 CI 文件了；GitLab 依靠读取项目根目录下的 .gitlab-ci.yml 文件来执行相应的 CI 操作：

#only:# - master

variables: IMAGE_TAG_NAME: "registry.api.weibo.com/cms-auto/fingerprint:${CI_COMMIT_SHORT_SHA}"

cache: untracked: true #cache all files that are untracked in your Git key: $CI_COMMIT_REF_NAME #-$CI_COMMIT_REF_NAME #-$CI_COMMIT_SHA paths: - .goBinTmp

after_script: - echo "after_script"

before_script: - echo "before_script" - hostname && cat /etc/*lease && ip a && env && pwd && ls -al - export GOPROXY=https://goproxy.io - export GOPATH="$CI_PROJECT_DIR/_vgo" - mkdir -p .goBinTmp

# 定义 stagesstages: - test - build - push_image - deploy

# 定义 jobjob_test: stage: test script: - echo "Testing is starting" - printf "mode=test\nlog_dir=/data1/ms/log/fingerprintGo/" > .env - go vet ./... #语法错误检查 - ping -c1 redis ## - go test $(go list ./...) - go test -v ./... # -benchmem -bench=. services: #docker link - name: redis alias: redis.test tags: - cms

# 定义 jobjob_build: stage: build script: - echo "Building is starting" - go build -race - cp fingerprint .goBinTmp/ tags: - cms

# 定义 deploypush_image: variables: # When using dind service we need to instruct docker, to talk with the # daemon started inside of the service. The daemon is available with # a network connection instead of the default /var/run/docker.sock socket. # # The 'docker' hostname is the alias of the service container as described at # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services # # Note that if you're using Kubernetes executor, the variable should be set to # tcp://localhost:2375 because of how Kubernetes executor connects services # to the job container DOCKER_HOST: tcp://docker:2375/ # When using dind, it's wise to use the overlayfs driver for # improved performance. DOCKER_DRIVER: overlay2 image: docker:stable services: - docker:dind# before_script:# - docker info# - echo "${DOCKER_DRIVER} ${DOCKER_HOST}" stage: push_image# when: manual #只能手动触发 script: - echo "Deploy to staging server "# - docker pull $CI_REGISTRY_IMAGE:latest || true - cp .goBinTmp/fingerprint fingerprint - docker build -f docker/Dockerfile -t ${IMAGE_TAG_NAME} . #--cache-from $CI_REGISTRY_IMAGE:latest - docker login registry.api.weibo.com --username "${REGISTRY_USER}" --password "${REGISTRY_PWD}" - docker push ${IMAGE_TAG_NAME} - docker run --name fingerprint-test -d -v /data1/ms/log:/data1/ms/log ${IMAGE_TAG_NAME} - sleep 5 - docker ps |grep -q 'fingerprint-test' - docker stop fingerprint-test && docker rm fingerprint-test environment: name: deploying only: - master tags: - cms

deploy: stage: deploy when: manual #只能手动触发 variables: CI_DEBUG_TRACE: "true" #debug tracing script: - docker run -it alpine/git clone 'https://${REGISTRY_USER}:${REGISTRY_PWD}@git.staff.sina.com.cn/cms/backend/FingerprintGo.git' - cd FingerprintGo - docker run -it alpine/git tag -a "${VERSION}" -m "${VERSION}" - docker run -it alpine/git push origin --tags - echo "kubectl set image deployment/fingerprint fingerprint=${IMAGE_TAG_NAME} -n fingerprint" tags: - cms only: - master artifacts: name: "$CI_JOB_NAME" paths: - .goBinTmp/* #go test will ignore

stagesstages 字段定义了整个 CI 一共有哪些阶段流程，以上的 CI 配置中，定义了该项目的 CI 总共分为 build、deploy 两个阶段；GitLab CI 会根据其顺序执行对应阶段下的所有任务；在正常生产环境流程可以定义很多个，比如可以有 test、publish，甚至可能有代码扫描的 sonar 阶段等；这些阶段没有任何限制，完全是自定义的，上面的阶段定义好后在 CI 中表现如下图

tasktask 隶属于stages 之下；也就是说一个阶段可以有多个任务，任务执行顺序默认不指定会并发执行；对于上面的 CI 配置来说 auto-build 和 deploy 都是 task，他们通过 stage: xxxx 这个标签来指定他们隶属于哪个 stage；当 Runner 使用 Docker 作为 build 提供者时，我们可以在 task 的 image 标签下声明该 task 要使用哪个镜像运行，不指定则默认为 Runner 注册时的镜像(这里是 debian)；同时 task 还有一个 tags 的标签，该标签指明了这个任务将可以在哪些 Runner 上运行；这个标签可以从 Runner 页面看到，实际上就是 Runner 注册时输入的哪个 tag；对于某些特殊的项目，比如 IOS 项目，则必须在特定机器上执行，所以此时指定 tags 标签很有用，当 task 运行后如下图所示除此之外 task 还能指定 only 标签用于限定那些分支才能触发这个 task，如果分支名字不满足则不会触发；默认情况下，这些 task 都是自动执行的，如果感觉某些任务太过危险，则可以通过增加 when: manual 改为手动执行；注意: 手动执行被 GitLab 认为是高权限的写操作，所以只有项目管理员才能手动运行一个 task，直白的说就是管理员才能点击；手动执行如下图所示。

cachecache 这个参数用于定义全局那些文件将被 cache；在 GitLab CI 中，跨 stage 是不能保存东西的；也就是说在第一步 build 的操作生成的执行文件，到第二部打包 docker image 时就会被删除；GitLab 会保证每个 stage 中任务在执行时都将工作目录(Docker 容器 中)还原到跟 GitLab 代码仓库中一模一样，多余文件及变更都会被删除；正常情况下，第一步 build 生成文件应当立即推送到文件服务器；但是这里测试没有搭建，所以只能放到本地；但是放到本地下一个 task 就会删除它，所以利用cache 这个参数将 build 目录 cache 住，保证其跨 stage 也能存在。

关于 .gitlab-ci.yml 具体配置更完整的请参考：

Gitlab CI yaml官方配置文件翻译

上面已经基本搞定了一个项目的 CI，但是有些变量可能并未说清楚；比如在创建的 PROJECT_ENV 文件中引用了$CI_COMMIT_REF_NAME、${CI_COMMIT_SHA} 等变量；这种变量其实是 GitLab CI 的内置隐藏变量，这些变量在每次 CI 调用 Runner 运行某个任务时都会传递到对应的 Runner 的执行环境中；也就是说这些变量在每次的任务容器 SHELL 环境中都会存在，可以直接引用，具体的完整环境变量列表可以从 官方文档 中获取；如果想知道环境变量具体的值，实际上可以通过在任务执行前用 env 指令打印出来，如下所示

在某些情况下，我们希望 CI 能自动的发布或者修改一些东西；比如将生成文件上传到镜像库、将 docker 镜像 push 到私服；这些动作往往需要一个高权限或者说有可写入对应仓库权限的账户来支持，但是这些账户又不想写到项目的 CI 配置里；因为这样很不安全，谁都能看到；此时我们可以将这些敏感变量写入到 GitLab 自定义环境变量中，GitLab 会像对待内置变量一样将其传送到 Runner 端，以供我们使用；GitLab 中自定义的环境变量可以有两种，一种是项目级别的，只能够在当前项目使用，如下

另一种是组级别的，可以在整个组内的所有项目中使用，如下

这两种变量添加后都可以在 CI 的脚本中直接引用。

对于 Kubernetes 集成实际上有两种方案，一种是对接 Kubernetes 的 api，纯代码实现；另一种取巧的方案是调用 kubectl 工具，用 kubectl 工具来实现滚动升级；这里采用后一种取巧的方式，将 kubectl 二进制文件封装到镜像中，然后在 deploy 阶段使用这个镜像直接部署就可以：

我用的是harbor, 镜像很方便搜索、维护：

手动触发完部署后，

最后， kubectl set image在产生环境使用时，需要经过领导审批、验证确认，所以暂不会直接上线，但这句命令随时可上线，哈哈。

关于 GitLab CI 上面已经讲了很多，但是并不全面，也不算太细致；因为这东西说起来实际太多了，现在目测已经 1W 多字了；以下总结一下 GitLab CI 的总体思想，当思路清晰了以后，我想后面的只是查查文档自己试一试就行了

CS 架构GitLab 作为 Server 端，控制 Runner 端执行一系列的 CI 任务；代码 clone 等无需关心，GitLab 会自动处理好一切；Runner 每次都会启动新的容器执行 CI 任务

容器即环境在 Runner 使用 Docker build 的前提下；所有依赖切换、环境切换应当由切换不同镜像实现，即 build 那就使用 build 的镜像，deploy 就用带有 deploy 功能的镜像；通过不同镜像容器实现完整的环境隔离

CI即脚本不同的 CI 任务实际上就是在使用不同镜像的容器中执行 SHELL 命令，自动化 CI 就是执行预先写好的一些小脚本

敏感信息走环境变量一切重要的敏感信息，如账户密码等，不要写到 CI 配置中，直接放到 GitLab 的环境变量中；GitLab 会保证将其推送到远端 Runner 的 SHELL 变量中

本文来自博客园，作者：sunsky303，转载请注明原文链接：https://www.cnblogs.com/sunsky303/p/10775126.html